In addition to fm or C files corresponding to the graphical user interface designer, the XFaceMaker products also generate files for the application proper and Maker files for compiling the whole application.
XFaceMaker generates four files corresponding to the whole application:
Main.c, containing the main function
of
the application; it initializes the
toolkit and the
XFaceMaker library, attaches application functions and active values and creates the GUI.
App.c, containing the skeletons of the
application functions as well as the
active value
variables; the user can then fill in the bodies of these functions.
App.h, containing the declarations of
the application functions and active
value variables;
Make, containing the rules to build the
application.
Generation of C code
for the GUI
XFaceMaker also generates C modules corresponding to the interface. These modules can then be compiled and linked with the application core to construct the full application. This is a true compilation process. The code generated corresponds to both the interface layout part and to the FACE script part that expresses the behavior. The FACE interpreter is no longer invoked in the C code generated. Thus, the C code is completely autonomous and can be used to build a stand-alone application.
Generation of C++ classes
and C++
applications
XFaceMaker 3.0 allows the generation of C++ classes corresponding to interface modules. A C++ class created using XFaceMaker can be viewed as a user defined wrapper for a widget tree. It provides a set of constructors and a destructor to control the creation and destruction of instances of the widget tree, plus a set of public member functions (methods) which permit its manipulation while hiding the details of its internal structure.
A C++ class always represents a widget tree, defined by its top widget. The members of the class are defined by means of active values associated with this widget. Data members as well as member functions can be defined. Data members correspond to active values with a per object storage, whereas member functions correspond to active values with a per call storage. By convention, data members are always private, but it can be required that access functions (set and get) be automatically generated. Member functions can be public or private, their body is defined in FACE like any active value script.
Two predefined "styles" of code are supported: the NSL style and the Rogue Wave Style. Choosing a style determines which class to use as a base class of the class generated, as well as the signature of the member functions.
The NSL style: the class generated is
derived from a predefined base class
which provides
constructors and useful member functions.
The Rogue Wave style: the class
generated is derived from a class of the
View.h++ library,
which is chosen automatically among the Widget wrappers (also called controllers)
provided by this library. Constructors and access functions for data members
are
defined following the conventions adopted in View.h++. Using this style generates
classes which are
easy to combine with classes of the View.h++ library.
XFaceMaker will also generate the X resource files, which are files used by the X server to set resources for an application at run-time.
Internationalization
XFaceMaker supports a very flexible and powerful approach to the internationalization of interfaces. The handling of internationalization is based on the X/Open Global Language Support (GLS) library and hence, is available only on systems that support GLS.
Essentially, internationalization means that all literal strings that are internationalized will be placed in a national catalogue selected on the base of an environment variable. Every internationalized string is identified by a unique code and searched for in the corresponding catalogue.
In XFaceMaker, every resource value in an interface can be internationalized in this way, as well as all strings that are assigned to a widget resource. This allows the quick generation of internationalized interfaces.
Working with several files
XFaceMaker 3.0 offers enhanced functionality that helps the interface designer to build interfaces split into several .fm files. XFaceMaker remembers the file an object was loaded from. When the GUI is saved XFaceMaker remembers the file it came from and stores it there. Selected files are checked to ensure that they are not already loaded, although it is also possible to load multiple instances of the same module if necessary.
Project files
A GUI split into a main file and secondary files can be grouped in a project file. Projects can be handled as a whole and XFaceMaker knows how to trace down the components to their files.
Building the application
Version 3.0 of XFaceMaker has become a genuine application development environment that assists the developer not only in the building of the GUI but also provides extensive assistance in the other phases of application development.
Modifying application files
XFaceMaker provides facilities for the automatic updating of all the application files whenever the GUI is edited and modified, saving the user the time consuming task of manually updating them.
Modifying application patterns
It may be useful or necessary to modify the application pattern files to suit the particular needs of a project. This can be done by changing the installed pattern files or by placing a copy in a different directory accessible by the XFaceMaker search rules.
It is also possible to modify the pattern information itself to control the way the application objects will be output in the application file.
